rippled 3.3.0 schema, three conformance guards, autofill fees and reconnect hardening (10.11.0.0) - #76

…гда (10.10.1.0) (#72)

* fix(client): исключение из OnConnected больше не убивает клиент навсегда (10.10.1.0)

Connection.OnceOpen ловил любое исключение потребительского обработчика
OnConnected и звал Disconnect() - пользовательский путь отключения:
_permanentlyDisconnected = true плюс ClearReconnectState(). После этого
клиент мёртв навсегда: реконнект-цикл не перезапускается, новых сокетов
не открывается, OnConnected больше не поднимается, а любой запрос падает
с NotConnectedException. Наружу при этом не выходило ничего - ни события,
ни лога.

Триггер - самый штатный сценарий: перезапуск ноды. OnConnected - типовое
место восстановления подписок (SDK их после реконнекта не восстанавливает),
а нода принимает TCP раньше, чем начинает отвечать на запросы, поэтому
первый subscribe уходит в RequestTimeout и падает. В проде так встал флот
ботов - по четыре часа тишины после обновления ноды.

Теперь сбой обработчика трактуется как отказ СОЕДИНЕНИЯ, а не как воля
пользователя: сокет сносится, дальше работает обычный реконнект с
экспоненциальным бэкоффом, флаг постоянного отключения не ставится.

Защита от вечного цикла: OnceOpen чистит реконнект-состояние до вызова
обработчика, поэтому счётчик попыток самого цикла обнуляется на каждом
успешном TCP-коннекте и сойтись не может. Подряд идущие сбои обработчика
считаются отдельно (_connectHandlerFailures, сбрасывается при успешном
прогоне обработчика, в Connect() и в ChangeServer()); при достижении
MaxReconnectAttempts с StopAfterMaxAttempts клиент осознанно сдаётся -
сразу понятный NotConnectedException вместо пятиминутного молчания.

Причина теперь наблюдаема: исключение поднимается через OnError с
errorMessage = "connectHandlerError" и через OnConnectionStatus.

Попутно: WebSocketClient.SendMessageAsync (async void, вызывается без
await) больше не глотает ошибку отправки молча - она трассируется.
Поведение не меняется, запрос по-прежнему ограничен RequestTimeout, но
причина перестала быть невидимой при диагностике.

TestUOnConnectedHandlerFailure закрывает все четыре свойства против
mock rippled: восстановление после разового сбоя, работоспособность
клиента после восстановления, отчёт через OnError и остановка вечно
падающего обработчика.

* fix(review): замечания CodeRabbit к PR #72

1. Детальная причина отказа терялась. SetConnectionState после Disconnect()
   - no-op: Disconnect() уже перевёл состояние в Disconnected, а
   SetConnectionState уведомляет только при смене состояния. Подписчик видел
   "Disconnected by user request." вместо причины. Уведомление перенесено
   перед Disconnect().

2. WaitForConnectionAsync проверял _permanentlyDisconnected один раз на входе
   и никогда - внутри цикла ожидания. Ждущий в Connect() вызывающий досиживал
   весь ConnectionAcquisitionTimeout (по умолчанию 5 минут) и получал общий
   TimeoutException вместо реальной причины. Проверка перенесена в цикл.

3. Личность сокета при разборе. WebSocketClient.Connect вызывает OnConnect без
   await, поэтому connect-лок отпускается, пока обработчик ещё выполняется, и
   к моменту разбора ws может указывать уже на новый сокет. Закрывается ровно
   тот сокет, для которого падал обработчик; ws обнуляется, только если всё
   ещё ссылается на него; если сокет уже не текущий - реконнект-состояние
   принадлежит новому соединению и не трогается.

   При этом тест на вечно падающий обработчик вскрыл гонку в самом фиксе:
   проверка "цикл реконнекта уже работает" гонится с выходом этого цикла - он
   прерывается сразу, как сокет отрапортовал Open, то есть ДО того, как
   обработчик успел упасть. Проигрыш гонки оставлял клиента без реконнекта -
   ровно тот клин, который правится. Вместо проверки путь теперь безусловно
   забирает владение: гасит текущий цикл и запускает новый, а пришедший позже
   OnceClose видит живой цикл и корректно отступает. Побочно: восстановление
   стало занимать сотни миллисекунд вместо десятков секунд.

4. Ошибка отправки: Debug.WriteLine вырезается без DEBUG, которого нет в
   релизной сборке. Мёртвый колбэк ошибки WebSocketClient (его никто не звал и
   не подписывал) теперь доносит исключение до Connection.OnError с
   errorMessage = "socketSendError". Только уведомление: неудачная отправка
   сама по себе не означает потерю соединения, реконнект не запускается,
   запрос по-прежнему ограничен RequestTimeout.

Отклонено: подъём версий Xrpl.AddressCodec / Xrpl.BinaryCodec / Xrpl.Keypairs
до 10.10.1.0. Эти пакеты в этом PR не менялись, версионируются независимо и
уже расходятся с основным на NuGet осознанно (Xrpl 10.10.0 против base 10.9.0;
так же было в 10.9.1.0 и 10.10.0.0). Публикация идёт с --skip-duplicate, так
что неизменные пакеты просто пропускаются, а подъём выложил бы побайтово те же
артефакты под новым номером.

Тест TestPermanentlyFailingOnConnectedHandlerStops усилен: теперь проверяет,
что ожидающий вызывающий разблокируется именно NotConnectedException.

* fix(review): вторая порция замечаний CodeRabbit к PR #72

1. Реконнект-цикл писал в чужую сессию. StopReconnectLoop() отменяет токен, но
   не дожидается цикла, поэтому снятый цикл мог добраться до тела или хвоста
   уже после того, как установлена замена, и обнулить _reconnectMode живого
   цикла, сбросить его _reconnectAttempts или выбросить его _reconnectCts.
   Дефект существовал и раньше (RetireCurrentSessionAndReconnectAsync снимает
   циклы ровно так же), но путь сбоя OnConnected делает его гораздо более
   достижимым. ReconnectLoopAsync теперь принимает CancellationTokenSource,
   которым владеет, и трогает общее состояние, только пока этот источник
   остаётся активным.

2. Mock-сервер в тестах не останавливался: CreateMockRippled.Start() создавал
   Server (его конструктор поднимает слушателя) и терял ссылку. Добавлен
   Stop(), TestUOnConnectedHandlerFailure зовёт его в TestCleanup.

* fix(client): ChangeServer на неподнятый сервер больше не убивает клиент

Тот же класс клина, что и основной фикс PR, но другой путь. Найдено при
прогоне Blazor-демо: переключение селектора сети на выключенную ноду.

ChangeServer ставил ГЛОБАЛЬНЫЙ _isIntentionalDisconnect = true, чтобы
отфильтровать поздние колбэки уходящего сокета, а сбрасывался этот флаг
только в OnceOpen. Если новый сервер не поднимался, OnceOpen не выполнялся
никогда: OnConnectionFailed читал отказ НОВОГО соединения как отключение по
воле пользователя, писал "Connection closed permanently.", не запускал
реконнект-цикл, и дальше всё - включая сам ChangeServer - падало с
вводящим в заблуждение "No connection attempt in progress. Call Connect()
first.". Поднятие сервера потом ничего не меняло: клиент был мёртв.

Поздние колбэки теперь фильтруются исключительно по-сокетному отслеживанием,
которое здесь и так уже было (_userInitiatedSockets плюс собственный флаг
сокета, выставляемый в RetireOldSessionAsync) - ровно так же, как всегда
делал путь ping-timeout / network-drop; в его коде даже висит комментарий,
предостерегающий от глобального флага именно по этой причине. Дополнительно
флаг явно гасится на входе, чтобы ChangeServer после пользовательского
Disconnect() не подавлялся оставшимся от него значением.

Дефект существовал до этого PR - проверено дважды: ни одна из строк этого
пути им не менялась, и одинаковый диагностический тест на чистом dev
(f17fc11) даёт байт-в-байт тот же вывод.

TestUChangeServerFailure закрывает оба случая: клиент доходит до нового
сервера, когда тот появляется, с предшествующим Disconnect() и без него.
Оба теста падают на dev и проходят с фиксом.

* fix(review): гонка старта и остановки mock-сервера в тестах

Start() выполняется на фоновом потоке, поэтому Stop() из TestCleanup мог
увидеть _server == null до присваивания и оставить живого слушателя.
Останов теперь фиксируется под локом: старт, завершившийся после него,
гасит собственный Server вместо того, чтобы его сохранить.

…тие DynamicMPT (10.11.0.0) (#71)

* feat(models): именованные lsf-флаги MPT и интеграционное покрытие DynamicMPT

Модели MPT отставали от rippled по флагам ledger-объектов, а DynamicMPT
(XLS-94) не имел ни гварда, ни интеграционных тестов: поля MutableFlags в
моделях были, но против ноды никогда не проверялись.

* MPTokenIssuanceFlags + MPTCanHoldConfidentialBalance (0x80) — вводит
  ConfidentialTransfer; остальная поддержка амендмента уже полная
  (транзакции 85-89, IssuerEncryptionKey/AuditorEncryptionKey,
  ConfidentialOutstandingAmount), не хватало только имени у флага
* MPTokenFlags + lsfMPTAMM (0x4) — пробел старше: флаг есть уже в 3.2.1.
  AMMCreate ставит его вместе с lsfMPTAuthorized, неявно авторизуя MPT-актив
  для псевдо-аккаунта AMM (src/libxrpl/tx/transactors/dex/AMMCreate.cpp)
* AmendmentGuard + DynamicMPT; id совпал с тем, что generate-amendments.sh
  уже кладёт в [amendments] nightly-стенда
* TestIDynamicMPT — 4 теста, каждый читает результат из ledger-объекта:
  MutableFlags с Create доезжают в LOMPTokenIssuance; MPTokenIssuanceSet
  меняет TransferFee и MPTokenMetadata, не переписывая MutableFlags;
  tmfMPTSetCanLock поднимает lsfMPTCanLock на issuance, созданном без него;
  мутация без разрешения отбивается tecNO_PERMISSION, а метаданные в ledger
  остаются прежними

Сценарии выверены по транзактору rippled 3.3.0-rc1
(src/libxrpl/tx/transactors/token/MPTokenIssuanceSet.cpp), а не по документации:
отсюда tfMPTCanTransfer на создании — preclaim требует lsfMPTCanTransfer уже
установленным, включение его той же транзакцией правило не удовлетворяет.

Проверено: nightly-стенд (3.3.0-b1, DynamicMPT enabled) — 4/4 passed;
CI-стенд (xrpld 3.2.0) — 4 skipped через гвард, exit 0; MPT-регрессия 28/28,
юнит-тесты 867/867. Значение 0x80 подтверждено на живом объекте:
MPTokenIssuanceSet с MutableFlags=0x40 даёт Flags=128.

* feat(models): флаги ledger-объектов по LedgerFormats.h и гвард против дрейфа

LedgerFormats.h — единственное место, где протокол объявляет, какие lsf-флаги
принадлежат какому ledger-объекту (definitions.json несёт коды полей и типы
объектов, но не значения флагов). Против него не стоял ни один тест, поэтому
пропущенный флаг не давал симптома: безымянный бит всё равно приходит в модель
числом, теряется только возможность проверить его по имени. Так lsfMPTAMM
прожил несколько релизов. Пофайловый диф всех enum'ов против тега 3.3.0-rc1
нашёл четыре пробела.

* MPTokenIssuanceFlags + MPTCanHoldConfidentialBalance (0x80) — от
  ConfidentialTransfer; значение подтверждено на живом объекте
* MPTokenFlags + lsfMPTAMM (0x4) — пробел старше, флаг есть уже в 3.2.1
* LOLoan.Flags — у объекта Loan вообще не было свойства Flags (нет его и в
  BaseLedgerEntry), то есть lsfLoanDefault/lsfLoanImpaired/lsfLoanOverpayment
  не читались типизированной моделью никак: статус дефолта и impairment займа
  был ненаблюдаем. Добавлено как LoanFlags?
* новые SignerListFlags и DirectoryNodeFlags — сами свойства Flags остаются
  raw uint (смена типа была бы breaking), enum'ы дают именованные константы
  вместо магических чисел; ложный комментарий у LODirectoryNode.Flags про
  «протокол не определяет флагов» исправлен

TestULedgerFlagsConformance — ledger-аналог TestUTxFormatConformance:
вендоренный Fixtures/LedgerFormats.h с пином по sha, парсер, падающий громко
на незнакомом LSF_FLAG* и на тощем разборе, диф в обе стороны и требование
регистрировать каждый флагованный объект — новый объект роняет сборку, а не
пропускается молча. Проверен мутациями: неверное значение, удалённый флаг и
незарегистрированный объект дают внятное падение.

Интеграционное покрытие DynamicMPT (XLS-94): AmendmentGuard + TestIDynamicMPT,
4 теста, каждый читает результат из ledger-объекта. Сценарии выверены по
транзактору rippled, а не по документации.

Версия Xrpl поднята до 10.11.0.0 (minor: только добавления в публичном API),
base-пакеты не менялись. CHANGES.md дополнен.

Проверено: nightly-стенд — TestILoan/TestIDynamicMPT/TestIMPToken 41/41 passed;
юнит-тесты 869/869; сборка решения без ошибок.

* ci(protocol-watch): следить за LedgerFormats.h

TestULedgerFlagsConformance сравнивает модели с ПРИПИНЕННОЙ копией
LedgerFormats.h, поэтому сам по себе он не может заметить, что апстрим ушёл
вперёд — этот сигнал даёт protocol-watch. Заголовка в его списке не было, и
это вторая половина причины, по которой lsfMPTAMM прожил несколько релизов:
не только никто не сверял флаги, но и никто не сообщал, что файл изменился.

Заодно .ref фикстуры перестаёт врать: там написано «когда protocol-watch
сообщит об изменении этого файла — замени копию целиком», а вотчер за ним
не следил.

Путь отсутствует в baseline, поэтому первый же прогон отметит заголовок как
изменившийся один раз и внесёт его в baseline наравне с остальными — union
ключей в сравнении это предусматривает.

* feat(protocol): sfLEVersion — версия схемы Vault (rippled #7817)

protocol-watch сообщил 03.08 об изменении sfields.macro и ledger_entries.macro
на develop. Изменение одно: TYPED_SFIELD(sfLEVersion, UINT8, 6) и его появление
в ltVAULT как SoeDefault (rippled #7817, cash-basis accounting для LoanBroker).

Поле помечает, по какой схеме учёта живёт хранилище. Хранилища, созданные до
активации cash-basis, не несут LEVersion вовсе, и rippled трактует его отсутствие
как версию 0 (VaultVersion::Legacy), а не как ошибку — то есть отсутствие
значения осмысленно, это не потеря данных.

* definitions.json + сгенерированный Field.Uint8. Нужны ОБА: definitions.json
  в рантайме не читается, он вход для Tools/GenerateEnums, поэтому поле,
  добавленное только туда, не доезжает никуда. Файл перегенерирован
  инструментом, а не правился руками
* LOVault.LEVersion (uint?, как остальные UInt8-поля этого объекта) и enum
  VaultVersion (Legacy = 0, CashBasis = 1) — имена для значений, которые
  протокол определяет на сегодня
* TestULEVersion_BinaryRoundTrip — именно он показал, что одного definitions.json
  мало: до кодогенерации кодек поля не знал и тест падал
* TestULOVault_LEVersion_Deserialize — обе формы: поле присутствует, и legacy-
  хранилище без него десериализуется в null

Xrpl.BinaryCodec поднят до 10.10.0.0 (minor: добавлено поле). Остальные
base-пакеты не тронуты и сохраняют версии. Xrpl не бампится: 10.11.0.0 ещё
не выпущен и уже описывает модельные правки этой серии.

Проверено: сборка решения без ошибок, юнит-тесты 877/877.

* chore(release): выровнять версию Xrpl.BinaryCodec с Xrpl (10.11.0.0)

Кодек везёт sfLEVersion, то есть меняется вместе с моделями, — держать его на
собственной ветке нумерации незачем: потребитель читает один номер для обоих
пакетов. Вместо следующего минора кодека (10.10.0.0) ставится 10.11.0.0.

10.10.x просто пропускается: последняя опубликованная версия Xrpl.BinaryCodec —
10.9.0, номер 10.10.0.0 на NuGet не выходил, так что ничего не переиспользуется
и не переписывается.

Xrpl.AddressCodec и Xrpl.Keypairs остаются на 10.9.0.0 — они не менялись.

…_entries.macro (10.11.0.0) (#75)

* feat(models)!: гвард полей ledger-объектов и чистка моделей по ledger_entries.macro

Третья и последняя поверхность конформанса: TestUTxFormatConformance держит
поля транзакций, TestULedgerFlagsConformance — флаги ledger-объектов, а поля
самих объектов не проверял никто. ledger_entries.macro — единственное место,
где протокол объявляет состав объекта (definitions.json несёт коды полей и
типы, но не списки), и пропущенное поле симптома не даёт: чтение объекта
проходит, значение просто теряется.

Гвард:
* вендоренный Fixtures/ledger_entries.macro с пином по sha. Пин на develop,
  а не на тег (в отличие от LedgerFormats.h): модели по полям следуют develop,
  и sfLEVersion существует только после 30.07 — тег объявил бы его выдумкой SDK
* диф в обе стороны + обязательная регистрация каждого объекта, поэтому новый
  ledger-объект роняет сборку, а не пропускается
* четыре common-поля rippled (LedgerIndex, LedgerEntryType, Flags, Sponsor из
  LedgerFormats::getCommonFields()) исключаются с обеих сторон, как это уже
  сделано для commonFields в TxFormat-гварде; [JsonIgnore]-свойства не в счёт
* проверен мутацией: переименование JsonPropertyName даёт обе половины отчёта

Удалены свойства, которых нет в протоколе (BREAKING, без [Obsolete] — как при
удалении инертных ConnectionOptions в 10.10.0.0). Значение они держать не могли:
объект собирается по фиксированному SOTemplate. Проверено и на живой ноде, и по
четырём версиям (3.2.1, 3.3.0-b1, 3.3.0-rc1, develop) — нет нигде:
* LOVault.DomainID — positive control: VaultCreate с Data, AssetsMaximum и
  DomainID прошёл, первые два вернулись на объекте, DomainID — нет, он уехал
  на связанный share MPTokenIssuance
* LOLoan.PrincipalRequested — поле транзакции LoanSet; реальный займ хранит
  сумму как PrincipalOutstanding
* LOCredential.OwnerNode — у объекта IssuerNode/SubjectNode; нулевые hint'ы
  сериализуются ("OwnerNode":"0" у Loan), так что отсутствие настоящее
* LONFTokenPage.NFTokenPage, LOAmm.LedgerCurrentIndex, LOAmm.Validated —
  последние два принадлежат конверту ответа amm_info (snake_case)

Починено в LOAmm:
* AMMAccount никогда не десериализовался — поле объекта называется Account,
  а атрибута не было; имя свойства не меняется, вызовы не ломаются
* конструктор ставил LedgerEntryType.AccountRoot вместо AMM

Добавлены PreviousTxnID/PreviousTxnLgrSeq в LOAmm, LOAmendments,
LODirectoryNode, LOFeeSettings, LONegativeUNL.

Xrpl 10.11.0.0 -> 10.12.0.0. Xrpl.BinaryCodec не менялся и остаётся 10.11.0.0.

Проверено: юнит-тесты 879/879; на nightly-стенде TestILoan/TestIVault/
TestICredential/TestINFToken/TestIAmm — 64/64; сборка решения без ошибок.

* chore(release): схлопнуть невыпущенные 10.10.1.0 / 10.11.0.0 / 10.12.0.0 в один 10.11.0.0

На NuGet последняя опубликованная версия Xrpl — 10.10.0. Значит 10.10.1.0
(фикс OnConnected), 10.11.0.0 (флаги ledger-объектов, гвард по LedgerFormats.h,
DynamicMPT, sfLEVersion) и 10.12.0.0 (гвард полей ledger-объектов и чистка
моделей) существуют только в dev и ни один из номеров наружу не уходил.

Три раздела CHANGES.md слиты в один 10.11.0.0 от 08/04/2026, версия пакета
Xrpl откачена с 10.12.0.0 на 10.11.0.0. Потребитель получит один релиз вместо
трёх номеров, из которых два никогда не существовали как артефакты.

Xrpl.BinaryCodec уже стоял на 10.11.0.0 — после схлопывания он совпадает с Xrpl
ровно, как и задумывалось при выравнивании. AddressCodec и Keypairs остаются
на 10.9.0.0: они не менялись.

Проверено: сборка решения без ошибок, юнит-тесты 879/879.

* refactor(review): нитпики CodeRabbit к PR #75

* LONegativeUNL: добавлен using System.Text.Json.Serialization и атрибуты
  сокращены до [JsonPropertyName] — как в LOAmendments, LODirectoryNode,
  LOFeeSettings и LOAmm. Полная форма стояла потому, что файл этот namespace
  не импортировал; теперь импортирует
* RippledLedgerEntryFormats: парсер падает на повторно объявленном объекте
  вместо тихой перезаписи. Индексаторное присваивание позволяло второму
  объявлению вытеснить первое — объект молча уходил из таблицы конформанса,
  а fieldCount продолжал расти, так что порог минимального разбора потерю
  не замечал. Это ровно тот класс тихого отказа, против которого написан
  остальной парсер

Дубликатов имён в текущей фикстуре нет (единственный LEDGER_ENTRY_DUPLICATE —
DepositPreauth, и обычного объявления с этим именем не существует), так что
гвард forward-looking. Проверен мутацией: дублирование блока Ticket даёт
"Ticket: declared twice in ledger_entries.macro"; фикстура после проверки
восстановлена и снова байт-в-байт совпадает с пином.

Проверено: сборка без ошибок, юнит-тесты 879/879.

)

* fix(client): синхронизировать жизненный цикл сессии переподключения

volatile делает атомарным каждое отдельное обращение, но не их последовательность.
StopReconnectLoop читал _reconnectCts трижды подряд — Cancel, Dispose, = null —
и старт, попавший между этими обращениями, получал свой свежий источник
уничтоженным уходящим стопом. Цикл оставался с мёртвым источником, отступал по
проверке владения, а замену никто не запускал: клиент вставал навсегда — ровно
тот исход, против которого писалась вся эта область.

Введён _reconnectStateLock, накрывающий каждое чтение-с-изменением тройки
_reconnectCts / _reconnectLoop / _reconnectAttempts во всех четырёх точках
записи: RetireCurrentSessionAndReconnectAsync (замена сессии и её же успешное
завершение), StopReconnectLoop, StartReconnectLoop и хвост ReconnectLoopAsync.
Решение «цикл уже идёт / источник переиспользуем / ставим новый / отдаём его
циклу» стало одной транзакцией — иначе гонка давала два живых цикла либо цикл
с уже уничтоженным источником.

Под локом не выполняется ничего, что может позвать потребительский код: отмена и
освобождение отставленного источника вынесены за лок, а ReconnectLoopAsync
начинается с await Task.Yield(), поэтому старт цикла под локом только планирует
его и возвращается — уведомление не выполняется на стеке вызывающего. Без этого
Disconnect из обработчика мог бы войти в тот же лок и заклинить.

volatile у поля сохранён: проверки владения в цикле читают его вне лока, а
одиночное чтение ссылки атомарно и ничего не изменяет.

TestUReconnectSessionRaces — и сразу оговорка: эти тесты НЕ воспроизводят
исходную гонку. Окно шириной в несколько инструкций из публичного API, где между
вызовами лежат целые await'ы, не достаётся: с убранным локом тесты по-прежнему
проходят (проверено мутацией, три прогона). Ценность у них обратная — сам лок
создаёт риск взаимной блокировки, и они гоняют конкурентные ChangeServer и
Disconnect, требуя, чтобы клиент затем дошёл до живого сервера. Дедлок или
потерянная сессия проявятся здесь, а не в бою.

Проверено: юнит-тесты 882/882; TestIConnectionStates 7/7 на CI-стенде; сборка
решения без ошибок.

* fix(client): не читать Token после yield и перезапускать цикл одной транзакцией

Селф-ревью предыдущего коммита нашло два дефекта, один из которых внесён им же.

* ObjectDisposedException в ReconnectLoopAsync. Добавленный await Task.Yield()
  стоял ПЕРЕД чтением ownCts.Token, а Cancel/Dispose отставленного источника
  вынесены за лок — значит за время ожидания продолжения другой поток успевал
  уничтожить именно этот источник, и обращение к .Token бросало
  ObjectDisposedException вне всякого try. Таск падал, не сделав ни одной
  попытки переподключения, а исключение терялось как unobserved. До прошлого
  коммита Token читался синхронно, так что окна не было вовсе — оно возникло
  ровно из-за yield. Теперь Token читается ДО yield, пока вызывающий ещё держит
  лок и источник заведомо жив; Task.Delay(delay, ct) дополнительно ловит
  ObjectDisposedException и трактует его как отставку, а не как сбой
* RestartReconnectLoop. Последовательность StopReconnectLoop(); _reconnectLoop =
  null; StartReconnectLoop(seed) брала лок дважды, а запись между вызовами шла
  без лока. Конкурентный старт из OnceClose или OnConnectionFailed успевал
  поставить свой цикл, после чего засеянный старт видел живой цикл и молча
  выходил, не применив seed — тихий откат роста бэкоффа, ради которого seed и
  вводился. Retire, установка нового источника, счётчика и запуск цикла делаются
  одной транзакцией под локом
* XML-док у _reconnectStateLock больше не утверждает, что лок покрывает «every
  read-modify-write»: перечислены места, которые он реально охватывает, и явно
  названы оставшиеся вне его (per-iteration инкремент, сбросы в ChangeServer и
  OnceClose)

Проверено мутацией: если в RestartReconnectLoop не применять seed,
TestRepeatedOnConnectedFailuresBackOff падает и показывает ~90 переподключений
подряд с ровным интервалом ~200 мс. Юнит-тесты 882/882.

* fix(demo): показывать фактический сервер после неудачной смены

Blazor-демо обновляло CurrentServerUrl только при успешном ChangeServer:
присваивание стояло в try сразу после await. ChangeServer переключает цель
клиента ДО попытки подключения, поэтому при переходе на недоступный сервер он
бросает по таймауту получения соединения — а клиент к этому моменту уже
переподключается к НОВОМУ адресу. Метка же продолжала показывать прежний
сервер.

Дальше ломалась и кнопка: гвард "Already connected to this server" сравнивал
выбранный адрес с этим устаревшим значением и отказывался переключаться обратно
на сервер, к которому клиент на самом деле подключён не был.

Присваивание перенесено в finally, то есть выполняется независимо от исхода.
SDK тут ни при чём: connection.GetUrl()/client.Url() возвращает новый адрес
сразу после ChangeServer.

Проверено вручную в демо против локальной ноды 3.2.1: переключение на
ws://127.0.0.1:19997 (порт мёртв) — метка показывает 19997, а не прежний
mainnet; последующее переключение на ws://localhost:6006 проходит и
подключается за 0.3 с, тогда как раньше отбивалось сообщением
"Already connected to this server".

* fix(client): снимать ссылку на цикл внутри стоп-транзакции

Замечание CodeRabbit к PR #78 (Major). StopReconnectLoop обнулял _reconnectCts,
но оставлял _reconnectLoop. Отставленный цикл выходит асинхронно — он узнаёт о
потере владения только на следующей проверке, — поэтому оставшаяся ссылка даёт
такую последовательность: StartReconnectLoop видит !IsCompleted и возвращается,
ничего не запустив, а отставленный цикл тут же отступает по проверке владения.
Не остаётся никого, кто бы переподключался. Достижимо, когда Connect или
ChangeServer гасит живой цикл, а новое подключение падает. Ссылка снимается в
той же транзакции под локом.

Нитпики оттуда же:
* TestUReconnectSessionRaces: финальный Connect обёрнут, чтобы падал ассерт с
  внятным текстом, а не сырое исключение от проигравшего гонку переключения
* StartMock вызывает mock.Start() напрямую: он биндит, слушает и уходит в
  BeginAccept, не блокируя, так что возврат из него уже означает готовность
  порта. Обёртка в поток лишь открывала окно, где тест успевал подключиться
  раньше mock'а. В соседнем TestUChangeServerFailure обёртка осталась —
  отдельная уборка, этот PR его не трогает

TestFailedConnectDuringReconnectLeavesLoopRunning закрывает функциональный путь
(Connect во время реконнекта, сервер появляется позже). Гонку он НЕ пинит: нужно,
чтобы отставленная задача была ещё жива в момент проверки IsCompleted, а к
приходу неудачного Connect она обычно уже вышла — с откаченным фиксом тест
проходит. Это записано в его XML-доке, чтобы его не приняли за регрессионный.

Проверено: юнит-тесты 883/883.

* feat(sugar): комиссии LoanSet/LoanPay/ConfidentialMPT в Autofill

Три транзактора со специальной базовой комиссией считались как обычные,
и все три — в сторону НЕДОплаты: комиссия ниже требуемого минимума
отклоняется с telINSUF_FEE_P, а не дотягивается сетью.

LoanSet: плоское baseFee*2 верно только при одиночной подписи контрагента.
LoanSet::calculateBaseFee берёт по одной базовой комиссии за каждую запись
CounterpartySignature.Signers. Если подпись уже проставлена — считаем её
записи напрямую; если нет (обычный порядок в autofill) — запрашиваем
signer list контрагента, как это делает xrpl.js.

LoanPay: LoanPay::calculateBaseFee умножает ВЕСЬ Transactor-костыль,
включая подписи, на один инкремент за каждые kLoanPaymentsPerFeeIncrement (5)
платежей, с потолком kLoanMaximumPaymentsPerTransaction/5 (20). Оценка читает
объект Loan, считает платёж как roundPeriodicPayment(PeriodicPayment, LoanScale)
+ LoanServiceFee и делит на него Amount транзакции. Все ветки, где rippled
возвращает normalCost, воспроизведены: tfLoanFullPayment/tfLoanLatePayment,
PaymentRemaining <= 5 и недоступный объект Loan.

ConfidentialMPT (5 типов): Transactor::calculateBaseFee вызывается с
kConfidentialFeeMultiplier = 9 — десять базовых комиссий за одиночно
подписанную транзакцию. Автозаполнялись одной, т.е. в 10 раз меньше.

12 юнит-тестов на новые формулы; весь набор TestU (895) зелёный.

* fix(sugar): current-леджер и защита от переполнения в комиссиях займов

Замечания CodeRabbit к PR #81.

account_info контрагента LoanSet и ledger_entry объекта Loan запрашивались
на validated-леджере. SignerListSet или LoanSet, попавшие в последний леджер,
там ещё не видны: в первом случае комиссия считается по одной подписи вместо
списка, во втором объект Loan выглядит недоступным и множитель платежей
теряется — обе ошибки в сторону недоплаты. Оба запроса переведены на current,
как это уже делает SetNextValidSequenceNumber.

Проверка потолка платежей масштабировала regularPayment вверх: PeriodicPayment
у верхней границы decimal ронял autofill с OverflowException. Сравнение
переставлено на деление amount на константу, которое переполниться не может.

Кламп оценки платежей по PaymentRemaining, предложенный в том же ревью,
не применён: LoanPay::calculateBaseFee читает sfPaymentRemaining только как
short-circuit <= 5 и не ограничивает им оценку. Кламп дал бы 2 инкремента там,
где сеть требует 20, то есть недоплату и telINSUF_FEE_P.
Зафиксировано тестом FewPaymentsRemainingWithLargeAmount.

…ина nightly (#83)

* ci: bump standalone stand to rippled 3.3.0

* feat(models)!: ImmutableFlags и дельты SponsorshipSet по схеме rippled 3.3.0

Стенд перешёл на релиз 3.3.0, что включает Sponsor, DynamicMPT, BatchV1_1,
PermissionDelegationV1_1 и ConfidentialTransfer на генезисе — 44 теста, ранее
скипавшихся через AmendmentGuard, начали выполняться, и 17 из них упали: обе
фичи были реализованы против nightly-сборки 3.3.0~b1 от 11.07.2026, а до релиза
upstream поменял их схему.

DynamicMPT:
- sfMutableFlags переименовано в sfImmutableFlags (тот же UInt32 nth 53, те же
  значения битов) с инверсией смысла: установленный бит означает «заморожено»,
  а не «разрешено менять». Выпуск без поля теперь полностью изменяемый —
  противоположность прежнему поведению
- MPTokenIssuanceCreateMutableFlags и MPTokenIssuanceSetMutableFlags заменены
  общим MPTokenIssuanceImmutableFlags (tif* = lsif*)
- включение возможности переехало из отдельного поля в флаги транзакции:
  MPTokenIssuanceSetFlags пополнен tfMPTSet* (0x04–0x100)

Sponsor:
- SponsorshipSet принимает FeeAmountDelta (Amount 34) и RemainingOwnerCountDelta
  (Int32 2) вместо абсолютных FeeAmount/RemainingOwnerCount, которые остались
  полями только у объекта Sponsorship. Старые поля нода отвергает на разборе:
  STObject::applyTemplate → «Field 'FeeAmount' found in disallowed location»
- клиентская валидация повторяет preflight: дельты ненулевые, FeeAmountDelta в
  XRP, при tfDeleteObject модификационные поля запрещены
- добавлен Common.TryGetInt32 для знаковой дельты

Фикстуры гвардов перепиныны на тег 3.3.0 (transactions.macro, LedgerFormats.h);
ledger_entries.macro остаётся на develop из-за sfLEVersion. RippledLedgerFlags
научился читать lsif*-константы, которые в 3.3.0 объявлены вне LEDGER_OBJECT, и
падает, если не нашёл ни одной.

Пин nightly-стенда сдвинут на 3.4.0~b0+202608111815.26cc683e, конфиг
перегенерирован с того же ref: Definitions Watch поднимает стенд именно из него,
поэтому устаревший пин делал еженедельный мониторинг слепым к этим двум
переименованиям.

* ci: еженедельный сторож пина nightly-стенда

definitions-watch поднимает стенд из ARG XRPLD_VERSION, поэтому устаревший пин
сужает еженедельную проверку до состояния rippled на момент последнего касания
пина: оба переименования 3.3.0 месяц просидели за пином от 11.07. Снять пин
нельзя — формат таймстампа nightly-сборок сократился с 14 до 12 цифр, и порядок
версий Debian ставит старые сборки выше новых.

- .ci-config/bump-nightly-pin.sh: берёт свежую сборку xrpld из nightly-канала,
  переписывает ARG XRPLD_VERSION и перегенерирует rippled.batchv11.cfg по
  develop-коммиту, зашитому в саму версию — конфиг и бинарник не могут разойтись.
  Режим --check только отчитывается: текущий пин, свежая сборка, возраст пина
- .github/workflows/nightly-pin-watch.yml: раз в неделю; бампает, когда пин
  старше MAX_PIN_AGE_DAYS (21), поднимает стенд на новом пине, требует
  включённого на генезисе AMM-сентинела и прикладывает к PR дифф definitions
  против новой сборки. Учётки, идемпотентность и запасной путь через
  tracking issue — как в release-watch

* fix(ci): валидное имя ветки в nightly-pin-watch и правка changelog

Замечания CodeRabbit к PR #83.

- имя ветки собиралось из версии xrpld как есть, а `~` git в ref не пускает:
  `git checkout -b` упал бы и PR с бампом не создавался. Версия чистится по
  классу допустимых символов, а не по одному символу текущего формата, плюс
  проверка через git check-ref-format перед использованием
- в секции 10.11.0.0 CHANGES.md остались пункты, описывающие MutableFlags и
  tmfMPTSet* как актуальный API, хотя тот же релиз их и заменяет. Приведены к
  ImmutableFlags/tfMPTSet*; более ранние секции не тронуты — они описывают
  состояние API на момент своего релиза

---------

Co-authored-by: github-merge-queue <github-merge-queue@users.noreply.github.com>

…брыва (#84)

* fix(tests): мок-сервер переставал принимать соединения после одного обрыва

Причина флейка TestConcurrentChangeServerKeepsClientRecoverable: unit упал на
push-прогоне dev, тогда как тот же коммит в PR-прогоне прошёл.

Server.connectionCallback вызывал BeginAccept последней строкой try-блока,
поэтому любое исключение выше по телу навсегда обрывало приём соединений. Пир,
рвущий соединение во время handshake — ровно то, что порождают конкурентные
ChangeServer/Disconnect — глушил мок именно так. Со стороны всё выглядело
исправно: слушающий сокет оставался связан, порт числился занятым, TCP-соединения
устанавливались ядром, и клиент видел сервер, который принял подключение и молчит.
Отсюда 2m06s у упавшего прогона против 10s у обычного и сообщение, обвиняющее
клиент в том, что он «не дошёл до живого сервера».

- BeginAccept перезапускается безусловно после колбэка, чем бы тот ни кончился;
  ObjectDisposedException обрабатывается отдельно и без перезапуска — он означает,
  что Stop() закрыл listener
- сокет, чей handshake упал, закрывается, а не течёт до конца процесса
- TestUMockRippledAcceptLoop фиксирует поведение: обрыв на handshake (RST через
  LingerOption(true, 0)) поодиночке и десять подряд, затем обычный клиент, который
  обязан подключиться. На старом колбэке оба падают, после фикса проходят за 0.6s
- TestUtils.MockCompletesHandshake: проба реальным WS-upgrade. Упавший
  reconnect-тест теперь сообщает, отвечает ли мок, — глухой сервер больше не
  будет прочитан как баг клиента. Проба покрыта на живом моке, свободном порту и
  слушающем сокете, который никогда не принимает

* docs(changes): убрать запись о фиксе мок-сервера из changelog

Правка чисто в тестовой инфраструктуре: код SDK не менялся, потребителю
пакета изменение не видно, поэтому в changelog релиза ему места нет.
Разбор причины остаётся в описании PR и в комментариях к самому коду.

…с неизвестного LedgerEntryType (#85)

* perf(json): кэш производных JsonSerializerOptions + фикс неизвестного LedgerEntryType

Полиморфные конвертеры (LOConverter, оба конвертера транзакций, MetaBinaryConverter,
LedgerBinaryConverter, LONFTokenConverter, GenericStringConverter<T>) заново входят в
сериализатор с удалённым собственным конвертером, и каждый вызов строил производные
JsonSerializerOptions с нуля. System.Text.Json кэширует метаданные типов per-instance,
а копирующий конструктор кэш не переносит — страница account_objects на 200 записей
перестраивала контракты 200 раз.

JsonSerializerOptionsCache строит их один раз на пару (исходные options, тип конвертера),
слабо ключуясь по исходному экземпляру. Безопасно: STJ замораживает options при первом
использовании, поэтому то, что конвертер получает на вход, измениться уже не может.

Попутно — LOConverter.DetermineType разрешал неизвестный LedgerEntryType в LOAccountRoot:
Enum.TryParse при неудаче пишет в out default(TEnum), а AccountRoot — нулевое значение,
и инициализация Unknown затиралась. Тип объекта новее SDK десериализовался как account root
с молча потерянными полями вместо отката к BaseLedgerEntry.

Снят //todo change from class to interface на AccountObjects.AccountObjectList: парсинг
работает как в transactionResponse с момента глобальной регистрации LOConverter, а
BaseLedgerEntry обязан оставаться конкретным классом именно как fallback для Unknown.

Тесты: TestUJsonSerializerOptionsCache (переиспользование экземпляра, изоляция по источнику
и типу конвертера), TestUAccountObjectsPolymorphism (разнотипная страница account_objects,
round-trip, неизвестный тип, страница на 200 записей), два теста в TestULOConverter.

* docs(json): уточнить механизм выигрыша от кэша и усилить его тесты

Селф-ревью показал, что заявленное обоснование неверно для .NET 8+. Пробник-конвертер,
записывающий полученный экземпляр options при разборе списка, видит один и тот же
экземпляр на всех элементах даже при копии-на-вызов: с .NET 8 STJ разделяет
caching-context между структурно равными options, поэтому метаданные типов не
перестраивались. Настоящая цена копии — аллокация, копирование списка конвертеров и
структурный поиск в пуле контекстов на каждое конвертируемое значение.

Оптимизация остаётся: 200 страниц account_objects по 200 записей — 456 мс / 47 МБ до,
217 мс / 29 МБ после; плюс снимается зависимость от пула контекстов, ограниченного 64
записями. Формулировки в XML-doc и CHANGES.md приведены к измеренному.

Deserialize_ReusesTheCachedOptionsInstance не проверял заявленного: обе стороны сравнения
читали кэш напрямую, тест оставался зелёным при откате LOConverter.Read на копию-на-вызов.
Заменён на Deserialize_GoesThroughTheCache — приватный экземпляр options, которого не
касается ни один другой тест, и проверка появления записи в кэше через internal
HasCachedEntry. Откат конвертера теперь роняет тест (проверено).

Добавлен WithoutConverter_LeavesTheSourceOptionsIntact: если Build когда-нибудь начнёт
снимать конвертер с исходного экземпляра вместо копии, XrplJsonOptions.Default потеряет
LOConverter на весь процесс, и раньше этого не поймал бы ни один тест класса.

* docs(json): убрать устаревший механизм из summary тестов кэша options